It is sometimes required to run the same computer application in different environments. Consider, for example, a program for statistical analysis that has to run on both a PC, managed by the Microsoft Windows operating system, and on a SUN workstation managed by SUN's SOLARIS operating system. The usual solution is to develop two different codes that fit to the two different environments, as illustrated on FIG. 2. Later, when new versions of the operating systems are introduced, further code versions of the application must be developed for the new operating system versions. There may, for example, be different code versions for different MS-Windows versions, such as Windows 98 and Windows XP. The number of different application versions has thus a tendency to grow. Consider the case, in which some errors have been detected in the code of the application. In this case, the code of each one of the different application versions must be corrected separately. Similarly, when there is a need to extend the application with some new functionality, the extensions must be introduced separately in each one of the different code versions. The development and later maintenance of an application that has to run in a number of different environments is, therefore, labor-intensive. One of the purposes of the present invention is to reduce the effort, required for developing and maintaining the code of an application that has to run in different environments. One of the goals of the present invention is that each application should be implemented by a single code that runs without any changes in all the different environments. Any detected bug need only to be corrected in one place it is in this single code. A further goal of the invention is to reduce the development and maintenance costs of the interface between the application and the operating environment including possible Graphical User Interfaces (GUI).
The current industrial practice in developing applications that have to operate in different environments, is to write the code in a programming language, for which compilers exist in all the targeted environments. The code needed in the different environments may, however, be different. This happens when the different environments employ different methods of interaction with the application. The different environments may for example employ different operating systems and different drivers for special hardware. The code of the application must in these cases be adapted to each one of these different environments. These adaptation efforts may be labor-intensive. These adaptation efforts may, however, be avoided by employing a modern cross-platform programming language like Java, which provides some of the operating system services. This enables to code the entire application, including the GUI (Graphical User Interface), to be written in the same language and run it in all the environments, in which the language operates. This ability of having the same code run in many different environments is sometimes denoted as “writing once and running everywhere”. This meets our goal of having only one single code to write and maintain.
There are, however, situations, in which the Java codes required for two different environments are still quite different. This may happen when there are differences in the employed hardware. One example is the code of the GUI employed on a large PC screen and the GUI code employed on a small screen of a cellular phone. The GUI employed on the PC may be large and, therefore, not fit in the small screen of the phone. A different, space-saving GUI must, therefore, be coded for the phone. For these kinds of situations further labor-saving methods have been developed. We shall now discuss these techniques.
We discuss first the technology that appears closest to our invention and which is described in the papers by J. Grundy, W. Zou and B. Yang (Grundy, J. C. and Zou, W.: An architecture for building multi-device thin-client web user interfaces. In Proceedings of the 14th Conference on Advanced Information Systems Engineering, Toronto, Canada, May 29-31 2002, Lecture Notes in Computer Science 2348). This method is concerned with adapting the user interface (UI) of a given Web application to different Web-enabled devices. In this method, the various pages of a Web application are specified using a set of custom Java Server Pages (JSP) tags. At runtime, the code of these JSP tags generates a UI adapted to the concrete device. The adaptation performed is the rearrangement of the structure and layout of the UI in order to fit to the device's presentational facilities, such as screen size. This work, however, does not consider such adaptations as selecting the UI controls that are most appropriate for the device, e.g., employing a drop-down menu instead of a set of radio buttons. The selection of the employed UI controls is performed by the developer, when she designs the application pages. This is illustrated by FIG. 5 in the paper by Grundy et al., which shows the authors' development environment. If it is, for example, required to run the application on both a small- and a large-screen device, the developer may select a space-saving drop-down menu for the small screen and large legible radio buttons for the large screen. There will, in other words, be two different versions of the JSP code for the two different devices.
This contrasts with our “one code version” goal.
We discuss now XWeb technology, presented in a paper by Olsen, D. R. Jr., Jefferies, S., Nielsen, T., Moyes, W., Fredrickson, P.: Cross-modal interaction using XWeb. UIST 2000 San Diego, Calif. (USA), 5-8 Nov. 2000. This approach provides tools for constructing both service-providing XWeb servers and corresponding XWeb clients. The data that an XWeb server can provide to XWeb clients are specified by Extensible Markup Language (XML) structures. Interactions are specified by special XML structures called XViews. For each application, the developer must specify its XViews. When moving the application to a platform with different characteristics it may be necessary to redesign the XView's to fit to the capabilities of the new platform. An application may therefore employ different XView codes on different platforms. This contrasts with our “one code version” goal.
We now discuss the approach elaborated by Mod G., Paterno' F., Santoro C.: CITE: Support for Developing and Analyzing Task Models for Interactive System Design. IEEE Transactions on Software Engineering, August 2002, pp. 797-813, and Mod G., Paterno' F., Santoro C.: Tool Support for Designing Nomadic Applications. Proceedings ACM IUI'03, Miami, pp. 141-148, ACM Press. The code of an application is structured in such a way, that the UI code may be relatively easily modified to fit to different platforms having different characteristics. In this approach, the UI code is a part of the code of the application. This means that we have different versions of the application code for different platforms. This contrasts with our “one code version” goal. Finally, we mention the paper by Gilroy, S. W., Harrison, M. D.: “Using Interaction Style to Match the Ubiquitous User Interface to the Device-to-Hand”. The 9th IFIP Working Conference on Engineering for Human-Computer Interaction, Tremsbüttel Castle, Hamburg, Germany, July 11-13,2004. This method assumes that in order to run a given application program on different computing platforms having different characteristics, different kinds of UI interaction styles may be needed. The experimental system described in the paper employs the “form fill”, the “dialogue style” and the “Menu style interaction style”. When it is required to run a given application on a given platform, an XML specification of an appropriate interaction style must be written by the developer of the application. This XML specification specifies how the abstract components of a UI of this style relate to the data and computations of this particular program. If it is required to run the application on a different platform, where a different kind of interaction style is appropriate, a corresponding new XML specification must be written. The developer may thus have to write different XML specifications for the different environments. This contrasts with our “one code version” goal. Note that the “interaction style” term employed above is different from the “interaction style” term employed in the later description of our invention.